User interface improvements for medical devices

ABSTRACT

A method and system is disclosed for operating a medical device with or without a cassette in place. A method is disclosed for adding additional VTBI to an ongoing infusion without stopping the infusion and with maintaining the infusion parameters. A method and system is disclosed for changing the CCA without having to interrupt or completely stop an ongoing infusion. Quick titration buttons are provided to allow improved navigation between various delivery display screens.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are hereby incorporated by reference under 37 CFR 1.57.

TECHNICAL FIELD

The present invention relates to medical devices. More specifically, theinvention relates to infusion pumps that include touch screen graphicaluser interfaces.

BACKGROUND OF THE INVENTION

Graphical user interfaces for medical devices that display patient andtreatment information have improved clinician efficiency when caring forpatients. However, a challenge for designing graphical user interfacesis the need to balance the amount of information displayed on any onescreen viewable be the clinician with the need to create a device thatis easy to read and navigate. Too often the user is presented with anoverwhelming amount of information, impeding the interaction between theuser and the user interface.

Additionally, medical devices, including medical pumps, can becomplicated and time-consuming for caregivers to program. The need foran improved graphical interface is critical to maintain efficiency ofpatient care and to reduce potential clinical errors and thereby improvepatient safety. Device interfaces that increase input efficiency andaccuracy are critical to improve patient safety and therapy.

Graphical user interface design must also take into account strictdesign parameters as well as safety parameters. As a result, manymedical devices do not provide flexibility in programming parameters,neither for the administrator nor for the clinician.

Therefore, it would be desirable to have a medical device that includesa graphical user interface that is easier to navigate, that allows foreasier programming of the medical device and that increases efficiencyand accuracy of the clinician programming and navigation.

To that end, it is an object of the invention to provide a medicaldevice that is programmable with or without a cassette in place.

It is another object of this invention to provide a medical devicewherein a change in clinical care area can be programmed withoutinterruption of an ongoing infusion.

It is another object of this invention to provide a medical device thatallows an additional volume to be infused (VTBI) to be programmed beforethe completion of an ongoing infusion.

It is another object of this invention to provide a medical device withimproved navigation buttons.

It is another object of this invention to provide a medical device thatallows the clinician to configure the display of infusion data.

It is another object of this invention to provide a medical device withimproved alarm features.

It is a further object of the invention to provide a configurabledose-back calculation feature.

SUMMARY OF THE INVENTION

A method and apparatus system is disclosed for operating a medicaldevice with or without a cassette in place. A method is disclosed foradding additional VTBI to an ongoing infusion without stopping theinfusion and with maintaining the infusion parameters. A method andsystem is disclosed for changing the CCA without having to interrupt orcompletely stop an ongoing infusion. Quick titration buttons areprovided to allow improved navigation between various delivery displayscreens.

The aforementioned and other features and advantages of the inventionwill become further apparent from the following detailed description ofthe presently preferred embodiments, read in conjunction with theaccompanying drawings. The detailed description and drawings are merelyillustrative of the invention rather than limiting, the scope of theinvention being defined by the appended claims and equivalents thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of the medication management systemincluding a medication management unit and a medical device, integratedwith an information system, in accordance with the present invention;

FIG. 2 is a schematic diagram of the medication management unit, inaccordance with the present invention;

FIG. 3 is a schematic diagram illustrating some of the major functionsperformed by the medication management unit, in accordance with thepresent invention;

FIG. 4 is a schematic diagram of a medical device, in accordance withthe present invention;

FIG. 5 is perspective view of a multi-channel medical device incommunication with a machine-readable input device according to thepresent invention and shows a split screen display, having one portionassociated with each channel, which is adapted to be displayed andviewed from afar during normal delivery of fluid, in accordance with thepresent invention;

FIG. 5A is a perspective view similar to FIG. 5 and illustrates a nearview display screen, in accordance with the present invention;

FIGS. 6A and 6B are screen shots of a graphical user interface forconfiguring a drug library parameter, in accordance with the presentinvention;

FIGS. 7A and 7B are screen shots of a graphical user interface forconfiguring medical device specific parameters, in accordance with thepresent invention;

FIG. 8 is a flow chart for a program for allowing or disallowingprogramming of a medical device in regards to the presence of acassette, in accordance with the present invention;

FIGS. 9A to 9G are screen shots of a graphical user interface,illustrating changing a clinical care area, in accordance with thepresent invention;

FIG. 10 is a flow chart for a program for changing a clinical care areain a multi-channel infusion pump, in accordance with the presentinvention;

FIG. 11 is a flow chart for a program for changing a clinical care areain a single channel infusion pump, in accordance with the presentinvention;

FIGS. 12A to 12F are screen shots of a graphical user interface,illustrating programming of additional VTBI to current infusion, inaccordance with the present invention;

FIG. 13 is a flow chart for a program for adding additional VTBI to acurrent infusion, in accordance with the present invention;

FIG. 14 is a screen shot of a graphical user interface for configuring adisplay setting at a drug library, in accordance with the presentinvention;

FIGS. 15A to 15C are screen shots illustrating a graphical userinterface for configuring a medical device display parameter, inaccordance with the present invention;

FIG. 16 is a flow chart for a program for determining a displayparameter, in accordance with the present invention;

FIGS. 17A to 17C are screen shots illustrating a graphical userinterface navigation button, in accordance with the present invention;

FIG. 18 is a flow chart for a program for determining a screen viewdisplay parameter, in accordance with the present invention;

FIGS. 19A to 19G are screen shots illustrating additional graphical userinterface navigation shortcut buttons, in accordance with the presentinvention;

FIG. 20 is a flow chart for a program for determining a screen viewdisplay parameter based on the navigation shortcut buttons, inaccordance with the present invention;

FIGS. 21A and 21B are screen shots of various graphical user interfacecall back alarms, in accordance with the present invention;

FIG. 22 is a flow chart for a program for responding to various callback alarms, in accordance with the present invention;

FIGS. 23A to 23C are screen shots illustrating graphical user interfacealarm navigation shortcut buttons, in accordance with the presentinvention;

FIG. 24 is a flow chart for a program for determining a screen viewdisplay parameter based on the alarm navigation shortcut buttons, inaccordance with the present invention;

FIG. 25 is a screen shot of a graphical user interface for configuring adose back calculation parameter at the drug library, in accordance withthe present invention;

FIGS. 26A and 26B are screen shots of a graphical user interface forconfiguring a dose back calculation at the medical device, in accordancewith the present invention; and

FIG. 27 is a flow chart for a program for allowing or disallowing a doseback calculation at the medical device, in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention will be described as it applies to its preferredembodiment. It is not intended that the present invention be limited tothe preferred embodiment. It is intended that the invention cover allmodifications and alternatives that may be included within the scope ofthe appended claims

With reference to FIG. 1 , the medication management system (MMS) 10 ofthe present invention includes a medication management unit (MMU) 12 anda medical device 14, typically operating in conjunction with one or moreinformation systems or components of a hospital environment 16. The termhospital environment should be construed broadly herein to mean anymedical care facility, including but not limited to a hospital,treatment center, clinic, doctor's office, day surgery center, hospice,nursing home, and any of the above associated with a home careenvironment. As discussed below, there can be a variety of informationsystems in a hospital environment. As shown in FIG. 1 , the MMU 12communicates to a hospital information system (HIS) 18 via a cachingmechanism 20 that is part of the hospital environment 16.

It will be understood by those of skill in art that the cachingmechanism 20 is primarily a pass through device for facilitatingcommunication with the HIS 18 and its functions can be eliminated orincorporated into the MMU 12 (FIG. 1 ) and/or the medical device 14and/or the HIS 18 and/or other information systems or components withinthe hospital environment 16. The caching mechanism 20 provides temporarystorage of hospital information data separate from the HIS 18, themedication administration record system (MAR) 22, pharmacy informationsystem (Ph1S) 24, physician order entry (POE) 26, and/or Lab System 28.The caching mechanism 20 provides information storage accessible to theMedication Management System 10 to support scenarios where direct accessto data within the hospital environment 16 is not available or notdesired. For example, the caching mechanism 20 provides continued flowof information in and out of the MMU 12 in instances where the HIS 18 isdown or the connectivity between the MMU 12 and the electronic network(not shown) is down.

The HIS 18 communicates with a medication administration record system(MAR) 22 for maintaining medication records and a pharmacy informationsystem (Ph1S) 24 for delivering drug orders to the HIS. Aphysician/provider order entry (POE) device 26 permits a healthcareprovider to deliver a medication order prescribed for a patient to thehospital information system directly or indirectly via the Ph1S 24. Oneskilled in the art will also appreciate that a medication order can besent to the MMU 12 directly from the Ph1S 24 or POE device 26. As usedherein the term medication order is defined as an order to administersomething that has a physiological impact on a person or animal,including but not limited to liquid or gaseous fluids, drugs ormedicines, liquid nutritional products and combinations thereof.

Lab system 28 and monitoring device 30 also communicate with the MMU 12to deliver updated patient-specific information to the MMU 12. As shown,the MMU 12 communicates directly to the lab system 28 and monitoringdevice 30. However, it will be understood to those of skill in art thatthe MMU 12 can communicate to the lab system 28 and monitoring device 30indirectly via the HIS 18, the caching mechanism 20, the medical device14 or some other intermediary device or system.

Delivery information input device 32 also communicates with the MMU 12to assist in processing drug orders for delivery through the MMU 12. Thedelivery information input device 32 can be any sort of data inputmeans, including those adapted to read machine readable indicia such asbarcode labels; for example a personal digital assistant (PDA) with abarcode scanner. Hereinafter the delivery information input device 32will be referred to as input device 32. Alternatively, the machinereadable indicia may be in other known forms, such as radio frequencyidentification (RFID) tag, two-dimensional bar code, ID matrix,transmitted radio ID code, human biometric data such as fingerprints,etc. and the input device 32 adapted to “read” or recognize suchindicia. The input device 32 is shown as a separate device from themedical device 14; alternatively, the input device 32 communicatesdirectly with the medical device 14 or may be integrated wholly or inpart with the medical device.

With reference to FIG. 2 , the medication management unit 12 includes anetwork interface 34 for connecting the MMU 12 to multiple components ofa hospital environment 16, one or more medical devices 14, and any otherdesired device or network. A processing unit 36 is included in MMU 12and performs various operations described in greater detail below. Adisplay/input device 38 communicates with the processing unit 36 andallows the user to receive output from processing unit 36 and/or inputinformation into the processing unit 36. Those of ordinary skill in theart will appreciate that display/input device 38 may be provided as aseparate display device and a separate input device.

An electronic storage medium 40 communicates with the processing unit 36and stores programming code and data necessary for the processing unit36 to perform the functions of the MMU 12. More specifically, thestorage medium 40 stores multiple programs formed in accordance with thepresent invention for various functions of the MMU 12 including but notlimited to the following programs: Maintain Drug Library 42; DownloadDrug Library 44; Process Drug Order 46; Maintain Expert Clinical Rules48; Apply Expert Clinical Rules 50; Monitor Pumps 52; Monitor Lines 54;Generate Reports 56; View Data 58; Configure the MMS 60; and Monitor theMMS 62. The Maintain Drug Library 42 program creates, updates, anddeletes drug entries and establishes a current active drug library. TheDownload Drug Library 44 program updates medical devices 14 with thecurrent drug library. The Process Drug Order 46 program processes themedication order for a patient, verifying that the point of care (POC)medication and delivery parameters match those ordered. The MaintainExpert Clinical Rules 48 program creates, updates, and deletes the rulesthat describe the hospital's therapy and protocol regimens. The ApplyExpert Clinical Rules 50 program performs logic processing to ensuresafety and considers other infusions or medication orders, patientdemographics, and current patient conditions. The Monitor Pumps 52program acquires ongoing updates of status, events, and alarmstransmitted both real-time and in batch mode, as well as tracking thelocation, current assignment, and software versions such as the druglibrary version residing on medical device 14. The Monitor Lines 54program acquires ongoing updates of status, events and alarms for eachchannel or line for a medical device 14 that supports multiple drugdelivery channels or lines. The Generate Reports 56 program provides amechanism that allows the user to generate various reports of the dataheld in the MMU storage medium 40. The View Data 58 program provides amechanism that supports various display or view capabilities for usersof the MMU 12. The Notifications 59 program provides a mechanism forscheduling and delivery of events to external systems and users. TheConfigure the MMS 60 program provides a mechanism for systemadministrators to install and configure the MMS 10. The Monitor the MMS62 program enables information technology operations staff capabilitiesto see the current status of MMS 10 components and processing, and otheraspects of day-to-day operations such as system start up, shut down,backup and restore.

With reference to FIG. 3 , the various functional programs 42-62 of theMMU 12, each including separate features and rules, are partitioned (ata higher level than shown in FIG. 2 ) and logically organized intointerrelated managing units of the MMU 12. As shown, the MMU 12 includesan asset manager 64, an alarm manager 66, a drug library manager (suchas, for example, is included in HOSPIRA MEDNET software) 68, a caregivermanager 70, a therapy manager 72, and/or a clinical data manager 73.However, one of ordinary skill in the art will appreciate thatadditional or alternative hospital system managing units can be providedwithout departing from the present invention. Additionally, the MMU 12includes a master adjudicator 74 between the separate interrelatedhospital system managing units 64-73 of the MMU 12, to regulate theinteraction between the separate management units.

Further, while the MMU 12 as described herein appears as a singledevice, there may be more than one MMU 12 operating harmoniously andsharing the same database. For example the MMU 12 can consist of acollection of MMU specific applications running on distinct servers inorder to avoid a single point of failure, address availabilityrequirements, and handle a high volume of requests. In this example,each individual server portion of the MMU 12 operates in conjunctionwith other server portions of the MMU 12 to redirect service requests toanother server portion of the MMU 12. Additionally, the masteradjudicator 74 assigns redirected service requests to another serverportion of the MMU 12, prioritizing each request and also ensuring thateach request is processed.

With reference to FIGS. 2 and 3 , the managing units 64-72 each includeseparate features and rules to govern their operation. For example, theasset manager 64 governs the execution of the Monitor Pumps 52 andMonitor Lines 54 programs; the drug library manager 68 governs theexecution of the Drug Library 42 and Download Drug Library 44 programs;the therapy manager 72 governs the execution of the Process Drug Order46, Maintain Expert Clinical Rules 48, and Apply Expert Clinical Rules50 programs; and the clinical data manager 73 governs the execution ofthe Generate Reports 56 and View Data 58 programs. Other distribution ofthe functional MMU programs 42-62 among the hospital system managingunits 64-73 can be made in accordance with the present invention.

With reference to FIG. 4 , an electronic network 114 connects the MMU12, medical device 14, and hospital environment 16 for electroniccommunication. The electronic network 114 can be a completely wirelessnetwork, a completely hard wired network, or some combination thereof.

FIG. 4 is a schematic diagram illustrating several functional componentsof a medical device 14 for implementing the present invention. Those ofordinary skill in the art will appreciate that the device 14 includesmany more components than those shown in FIG. 4 . However, it is notnecessary that all these components be shown in order to disclose anillustrative embodiment for practicing the present invention.

In the context of the present invention, the term “medical device”includes without limitation a device that acts upon a cassette,reservoir, vial, syringe, or tubing to convey medication or fluid to orfrom a patient (for example, an enteral pump, a parenteral infusionpump, a patient controlled analgesia (PCA) or pain management medicationpump, or a suction pump), a monitor for monitoring patient vital signsor other parameters, or a diagnostic, testing or sampling device.

With reference to FIG. 5 , for the purpose of exemplary illustrationonly, the medical device 14 is disclosed as an infusion pump. Moreparticularly, the medical device 14 can be a single channel infusionpump, a multi-channel infusion pump (as shown), or some combinationthereof.

With reference to FIG. 4 , the pump style medical device 14 includes anetwork interface 112 for connecting the medical device 14 to electronicnetwork 114. Where a wireless connection to the electronic network 114is desired, network interface 112 operates an antenna for wirelessconnection to the electronic network 114. The antenna can projectoutside the device 14 or be enclosed within the housing of the device.

A processor 118 is included in the medical device 14 and performsvarious operations described in greater detail below. The input/outputdevice 120 allows the user to receive output from the medical device 14and/or input information into the medical device 14. Those of ordinaryskill in the art will appreciate that input/output device 120 may beprovided as a single device such as a touch screen 122, or as a separatedisplay device and a separate input device (not shown). In the preferredembodiment, the display screen 122 of the medical pump 14 is a thin filmtransistor active matrix color liquid crystal display with a multi-wiretouch screen. A membrane generally impermeable to fluids overlays thedisplay screen 122 so the user can press on images of keys or buttons onthe underlying screen with wet gloves, dry gloves or without gloves totrigger an input.

A memory 124 communicates with the processor 118 and stores code anddata necessary for the processor 118 to perform the functions of themedical device 14. More specifically, the memory 124 stores multipleprograms formed in accordance with the present invention for variousfunctions of the medical device 14 including a graphical user interfaceprogram 126 with multiple subparts described in greater detail below.

With reference to FIG. 5 , the present invention provides amachine-readable input device 130. The machine-readable input device 130communicates with the medical device 14 to input machine-readableinformation to the medical device 14. The machine-readable input device130 can communicate, directly or indirectly, with the medical device 14via a wireless or hard-wired connection. The machine-readable inputdevice 130 can be a device that is separate from but associated or incommunication with the medical device 14. The machine-readable inputdevice 130 can be any sort of data input means, including those adaptedto read machine-readable indicia, such as a barcode scanner or handheldpersonal digital assistant (PDA). Alternatively, the machine-readableinput device 130 may be operable to read in other known forms ofmachine-readable information, such as radio frequency identificationtags (RFID), touch memory, digital photography, biometrics, etc.

With reference to FIG. 5 , the medical device 14 is a multichannel pumphaving a first channel 132 with first channel machine-readable label 134and a second channel 136 with a second channel machine-readable label138. A user of the medical device 14 operates the machine-readable inputdevice 130 to select a channel from one or more channels 132 and 136, byscanning in the associated machine-readable label 134 or 138.

The user selects the desired channel 132 or 136 by using themachine-readable input device 130 to scan a factory or hospitalprogrammed, unique, machine-readable label 134 or 138 that iselectronically generated and presented on the screen 122, preferablyjuxtapositioned near the respective channel 132 or 136. Alternatively,the machine-readable labels 134 and 138 are physically affixed to themedical device 14, preferably on or juxtapositioned near the channel 132and 136, respectively. Since the machine-readable labels 134 and 138 aregenerated and/or can be stored in memory 124 by the pump 14, the pump 14can associate the machine-readable labels 134 and 138 to the channels132 or 136. The pump 14 then allows the user to program and activate theselected channel 132 or 136. The user may also manually select thedesired channel by touching an appropriate folder tab on the touchscreen. The folder tabs are labeled and/or physically arranged on thescreen so as to be proximate to the corresponding channel 132 or 136.

In a further aspect of the wireless embodiment, all the medical devicescan periodically broadcast a unique wireless device/channel IP addressand/or a self-generated unique machine-readable label (for example, abarcode) 134 or 138 that can also be presented on the screen 122.Alternatively, the machine-readable labels 134 and 138 are physicallyaffixed to or posted on the medical device 14. Each medical device willcorrelate such broadcasted or posted device/channel IP addresses and/orbarcodes with a particular patient, who is also identified by a uniquemachine readable label (not shown) or patient IP address. The userassociates the desired pump(s) or channel(s) 132, 136 with the patientby using the machine-readable input device 130 to scan the uniquemachine-readable labels 134, 138 and the patient's machine readablelabel. This causes the appropriate pump processor(s) 118 to associatethe appropriate pump channel(s) 132, 136 with the patient. Then thepumps or channels can associate, communicate, and coordinate with eachother wirelessly.

With reference to FIGS. 4, 5, 5A and 17A to 17C, the graphical userinterface program 126 reallocates screen 122 for a medical device 14.Specifically, FIGS. 5 and 17B illustrates a multi-channel infusion pump14 with a split touch screen 122 having a first channel screen portion140 associated with first channel 132 and a second channel screenportion 142 associated with the second channel 136. Each channel screenportion 140 and 142 presents a subset of the delivery informationregarding the respective channels 132 or 136, including withoutlimitation therapeutic agent name, concentration, dose rate, VTBI, andalarm information, in a font size that it is easily readable by a userfrom a distance such as, for example, from approximately fifteen totwenty feet (4.6-6.2 meters) away. This is what is referred to as a “farview” delivery screen. The far view delivery screens display subsets ofthe information found on the relevant “near view” delivery screens,illustrated in FIGS. 17A and 17C. The near view delivery screen displaysinformation such as, drug name, concentration, dose rate, timeremaining, VTBI, volume remaining, and alarm name for the highestpriority alarm if in an alarm state.

In practice, the delivery screen displays a near view when the user isprogramming the device as illustrated by FIG. 5A. The near view deliveryscreen will switch to the far view delivery screen after a predeterminedperiod of time that is predetermined by the manufacturer, configurableby the facility via the drug library, and/or set by the caregiver at thepump, for example after 20 seconds. Often, the user does not want towait for the predetermined length of time to view the far screen. FIGS.17A to 17C illustrate one embodiment of a medical device that allows theuser to switch from the near view screen to the far view screen and viceversa at any time, in accordance with the present invention. FIG. 17Aillustrates a near view screen for channel A 1705. If, while in the nearview screen, the user wants to view the far view screen, the usertouches anywhere within the body 1710 of the near view screen. Touchingthe body 1710 of the near view screen displays the far view screen 1720illustrated in FIG. 17B. Referring to FIG. 17B, upon a user touching oneof the tabs “A” or “B” or anywhere on the channel screen portions 1725or 1730 of the far view delivery screen, a “near view” delivery screenis presented on the screen (FIG. 17C). In one embodiment, the usertouches a “hotspot” or special toggle button within the body of thecurrent display screen to return to either the far view screen or thenear view screen.

Referring to FIG. 18 , a flow chart for a program 1800 to immediatelytransition the display screen between the near view screen and the farview screen is illustrated. Program 1800 begins at block 1801 andprogresses to block 1802 where the program determines that the near viewdelivery screen is displayed. In one aspect of the invention, program1800 progresses in block 1804 to block 1803 when a near view time outelapses. In another aspect of the invention, program 800 moves fromblock 1802 to block 1803 when a user touches the near view hotspot inblock 1805. Program 1800 may return to the near view screen, block 1802,from the far view screen, block 1803, when a user touches the far viewscreen in block 1806.

Returning to FIG. 5 , the channel screen portion 140 or 142 selected orcorresponding to the tab selected expands in area but the size of atleast some of the text therein is shrunk, as shown in FIG. 17A Theshrinkage of one of the channel screen portions 140 and 142 andenlargement of its counterpart provides additional space for one or moredata display or data entry fields to be placed on screen 122, as shownin FIG. 5A. As discussed below, data displays or data entry fields areplaced on screen 122 in space previously occupied by portions of thechannel screen portion 140 or 142. This reallocation of space on screen122 perm its the user to enter inputs more easily since the data entryfield can be large, preferably at least as large or, more preferably,larger in area than the original channel screen portions 140 and 142were in the delivery screen mode. Additionally, the reallocation ofspace on screen 122 provides greater space for presenting information onthe channel being adjusted or monitored. Further details on thereallocation of screen 122 and the near view and far view deliveryscreens can be found in commonly owned and co-pending application U.S.Ser. No. 11/103,235 entitled USER INTERFACE IMPROVEMENTS FOR MEDICALDEVICES filed on Apr. 11, 2005, which is expressly incorporated hereinin its entirety.

Referring again to FIG. 5 , pump 14 includes dedicated or fixed tactileinfuser buttons, and images of buttons on the LCD-touch screen 122. Thefixed tactile buttons 133, 135, 137, and 139 provide the followingfunctions: LOAD/EJECT button 133—opens and closes the cassette carriage;ON/OFF button 135—turns power on and off; ALARM SILENCE button137—silences a silenceable alarm for a specified period of time, forexample two minutes; and EMERGENCY STOP button 139—stops all channels.

The LCD color touch screen 122 allows the user to access and useon-screen button images, for example 3D button images, and data entryfields. The touch screen 122 uses a membrane over the LCD display so asingle keypress does not cause significant infusion pole movement nor isit mistaken for a double keypress. The touch screen also accommodates akeypress whether the user is wearing wet gloves, dry gloves, or nogloves.

LCD touch screen button images 143, 145, 147 and 149A-149E are locatedas shown in FIGS. 5 and 5A and perform the following functions: PatientInformation Tab 143—displays the clinical care area, preselected patientinformation (including without limitation name, ID number, etc.), andprovides access to a more detailed patient information screen (FIG. 9C);Channel Level Therapy Buttons 145—accessed by button images on theinfuser touch screen, are used to select an infusion therapy; ProgramLevel Buttons 147—accessed by pressing areas, drop-down list triangles,boxes or text boxes on the programming screen, are used to select doseparameters of an infusion; and Device Level Buttons 149A-149E at thebottom of the touch screen are used to display and control device levelfeatures, including without limitation Mode 149A (for example,Operational or Biomed), Logs 149B, Locks 149C, Settings 149D, andCalculator display 149E. A wireless indicator image 102 displayed at thebottom of the screen 122 indicates that the device 14 is connected andready for communication.

By using the Channel Level Therapy Buttons 145 and the Program LevelButtons 147, the healthcare practitioner can program each individualchannel of the pump with specific fluid therapies in a variety of weightand body surface area-based units such as micrograms/kg/hour,grams/m2/hr, and other delivery specifications for the following modes:Basic Therapy-includes dose calculation, which allows dose rateprogramming based on volume to be infused (VTBI), drug amount, infusiontime and drug concentration and simple rate programming that allowsprogramming of volumetric rate (ml/hr) based upon VTBI and time; Bolusdelivery—allows user to program a single uninterrupted discrete deliverybased on dose amount and time (the bolus can be delivered from theprimary or a secondary container); Piggyback delivery—allows user toprogram the delivery of a secondary infusion, to be delivered throughthe same cassette as the primary infusion (the primary infusion ispaused until the piggyback VTBI completes); and Advanced Programming.Advanced Programming mode provides various types of programs including:Multistep-which allows a sequential delivery of fluid in up to 10 steps,with fluid volumes and delivery rates programmable for each step basedon Rate and Volume or Volume and Time; Variable Time—which allows up to24 dose calculation steps at specified clock times; Intermittent—acalculated dose or step to be delivered at regular intervals; andTaper—a delivery that ramps up and/or ramps down to a plateau rate.

With reference to FIGS. 4 and 5 , the graphical user interface 126provides channel indicators presented on screen 122. The channelindicators associate on-screen programming, delivery, and alarminformation with a particular delivery channel by using graphicaldepictions such as a channel indication icon 154, 155. The channelindication icon 154 or 155 is a graphical item clearly associatingon-screen programming, delivery, and alarm information with a specifiedassociated delivery channel. The channel indication icons 154 and 155are located on a tab 158 associated with a specified delivery channel ofthe medical device The channel indication icon 154 or 155 may includebut is not limited to a user readable letter or number, amachine-readable indicator 134, or a combination thereof. The graphicaluser interface program 126 also provides a drip indicator icon 160 andan infusion status icon 156 presented on screen 122.

With reference to FIGS. 4, 5, 5A and 19A to 20 , in one embodiment ofthe present invention, the graphical user interface 126 provides quicktitration buttons 1910, 1912 presented on a far view screen 122, 1922.FIG. 19A illustrates quick titration buttons for VTBI 1910 and Rate1912. In another or the same embodiment, graphical user interface 1922may also have a quick titration button for “dose” or other titrationparameters. Quick titration buttons 1910, 1912 operate as explode oractive buttons that when pressed take a user to a standard data entryfield for data entry when the button is selected. In this manner, withone press of a button the user can be quickly taken to the desired dataentry location rather than having to back track through several screensas is common. The quick titration buttons, thus, increase the user'sefficiency in programming the medical device in accordance with thepresent invention. FIGS. 19A to 19G illustrate the use of the VTBI quicktitration button 1910. In practice, the user presses quick titrationbutton 1910 (FIG. 19A) to bring up data entry field 1930 in FIG. 19B. Inthis embodiment, data entry field is a numerical keypad for entering avalue for the VTBI. Once the desired value 1935 is entered, the user isprompted to use the keypad to cancel the entry by pressing the cancelbutton 1940, delete the entry by pressing the clear button 1945, or savethe change and continue by pressing the enter button 1950 (FIG. 19C).FIG. 19D illustrates that the user pressed the enter button 1950 toaccept and change the VTBI entry. At the graphical user interfaceillustrated in FIG. 19D, the user has the option to press “Next A” 1955to continue, “Cancel Titration” 1960 to cancel the titration, or Options1965 to edit the program. FIG. 19E illustrates that the user pressed“Next A” 1955 to continue. FIG. 19E illustrates a confirmation screen1970. At this screen, the user is instructed to press “Start TitrationA” 1975 to confirm the VTBI change and begin the infusion. At screen1980 illustrated in FIG. 19F, the user can stop the titration bypressing “Stop Basic A” 1985. The near view screen 1980 illustrated inFIG. 19F returns to a far view screen 1990 shown in FIG. 19G.

FIG. 20 is a flow chart of a program 2000 for operating quick titrationbuttons for “dose,” “rate” and “VTBI” as discussed above. Program 2000begins at block 2001 and progresses to block 2005 which indicates thatthe pump is delivering an infusion and displaying the far view deliveryscreen (see FIG. 19A). Program 2000 moves to block 2010 when a userpresses one of the quick titration buttons 1910, 1912. In response tothe pressing of the quick titration button, at block 2015 the program2000 changes the display to the programming screen for the therapy whichis currently delivering (e.g. Channel A or B). After the transition tothe near view screen, program 2000 determines at blocks 2020 and 2025which button was pressed. If the program determines that the Dose buttonwas pressed the program displays the dose numeric keypad, block 2030. Ifthe program determines that the rate button 1912 was pressed, theprogram displays the rate numeric keypad. If the program determines thatneither the dose nor the rate button was pressed, the program displaysthe VTBI numeric keypad. Those with skill in the art will recognize thatprogram 2000 can determine which button was pressed in any order otherthan that described herein. Once the keypad for the chosen button isdisplayed, the user inputs the desired data and continues with theprogram to confirm and run the infusion with the changed parameter asdescribed above and illustrated in FIGS. 19A to 19G.

With reference to FIGS. 14 to 16 , in another aspect of the presentinvention, the drug library, located within the medication managementsystem and downloaded to the medical device, can be configured todisplay either the VTBI or the volume infused as a default setting onthe far view delivery screen. In another or the same embodiment, theuser can change the default setting at the medical device, as providedin more detail below.

With reference to FIG. 14 , illustrated is a screen shot of a graphicaluser interface 1400 for changing a plurality of settings of a druglibrary for a chosen CCA. In this example, the CCA is the Intensive CareUnit (ICU), though it should be understood that device settings forother CCAs may be similarly configured. The drug library includes drugand device related information, which may include but is not limited todrug name, drug class, drug concentration, drug amount, drug units,diluent amount, diluent units, dosing units, delivery dose or rate,medication parameters or limits, device/infuser settings and/or modes,CCA designations and constraints, and library version. Through themaintain drug library program 42 the drug library may be configured toprovide a medical device 14 that includes a customized display. In oneembodiment, the display is customized based on the Clinical Care Area(CCA) the medical device 14 is located in, assigned to, and/or to beassigned to.

Once the drug library graphical user interface 1400 for the chosen CCAis displayed, the administrator sets the “default far view setting” 1405to either VTBI 1410 or volume infused 1415. FIG. 14 shows that VTBI 1410has been selected as the default far view setting 1405.

With reference to FIGS. 15A to 15C, a user of a medical device having adefault far view setting 1405 can change the default setting. To changethe default far view setting 1405, the user presses settings button 1525to access the settings screen 1522. Next, the user presses the fardelivery screen button 1530 to access the settings far delivery screeninterface 1535 illustrated in FIG. 15B. In this illustration, thedefault setting was set to display VTBI 1545. To change the default todisplay “volume infused” the user accesses pull down menu 1550 (FIG.15C) by activating arrow 1540. Pressing the Volume Infused button 1555will change the default setting to display the volume infused instead ofthe VTBI. The user can press the save button (FIG. 15B) or the cancelbutton 1560 (FIG. 15C) for no change to the default setting.

With reference to FIG. 16 , illustrated is a flow chart of a program1600 for determining at the medical device whether the VTBI should bedisplayed or the volume infused should be displayed, as described above.Program 1600 begins at block 1601 and proceeds to block 1605 where thedisplay is about to switch from the near view to the far view. Prior tothe switch program 1600 determines the display parameter based on thedefault far view setting 1405 from the drug library for the CCA chosenby the user or the most recent setting established by the user at thedevice. Based on the current display parameter setting, program 1600determines at block 1610 whether to display the VTBI. If yes, program1600 proceeds to 1615 to display VTBI on the far view screen. If no,program 1600 moves to block 1620 to display the volume delivered on thefar view screen. Program 1600 ends at 1625. In another embodiment, thenear view screen display parameter settings could be similarlyconfigured and/or adjusted.

With reference to FIGS. 5, 6A and 6B, illustrated is graphical userinterface 600 of an input device 38 within MMU 12 that is used toconfigure, within a medication management system all of the associatedmedical devices 14 as a part of the master infuser setup 610. Pursuantto the present invention, graphical user interface 600 is used byauthorized personnel to configure medical device programming parameters.Infusion devices such as the pump 14 require an administration set toperform the infusion. In one embodiment, the administration set is acassette. The below discussion is in relation to a cassette, however,other types of administration sets as known in the art may be used inaccordance with the present invention. Prior art devices require thatthe cassette be in place prior to programming the pump for an infusion.There are some circumstances within the hospital environment, however,where this requirement is inefficient and wasteful of expensive suppliesthat go unused, merely because the clinical caregiver has set up aninfusion just in case it is need in, for example, the OR, ER or the ICU.In other situations, the time it takes to program a pump only when it isneeded may be harmful to the patient, especially in the OR and theemergency room. Conversely, disallowing the programming of a medicaldevice without a cassette may enhance patient safety by, for example,reducing the risk of line confusion during setup.

Therefore, in one aspect of the present invention, the drug library, viathe master infuser setup 610, can be configured by a hospitaladministrator based on hospital policy and procedure. FIGS. 6A and 6Billustrate the configurable parameter 620 of allowing programming ofinfusion pumps with or without a cassette in place. Thus, at graphicaluser interface 600, an administrator may choose to allow programmingwithout a cassette by selecting “yes” 630 (FIG. 6B) or disallowprogramming without a cassette by selecting “no” 640 (FIG. 6A). FIG. 7Aillustrates a warning message 720 that appears on screen 700 when a usertries to program the medical device without a required cassette. Oncethe cassette is loaded, the programming can continue. FIG. 7Billustrates how a programming screen would appear if the programming wasstarted with a cassette in place, whether or not required, or ifprogramming was started without a cassette which has been allowed by theconfiguration of the master infuser setup 610.

With reference to FIG. 8 , a flow chart of a program 800 for determiningat the medical device whether the drug library within the memory of themedical device allows the medical device to be programmed with orwithout a cassette in place. Program 800 begins at 801 and proceeds to805 where upon some user interaction (e.g. power on), program 800proceeds to block 810 where the program 800 receives an indication thatthe user is starting to program a therapy. Upon receiving theindication, program 800 determines at block 815 whether a cassette isrequired for programming. If no, the program allows the user to proceed,block 820 and the program ends at block 835. However, if at block 815 itis determined that a cassette is required, program 800 determines atblock 825 whether a cassette is in place. If yes, program 800 proceedsto block 820 to allow the user to continue and the program ends at 835.If, at block 825, program 800 determines that a cassette is not present,a warning message 720 is displayed that indicates to the user that acassette is required. The user may either place a cassette as requiredand continue or discontinue the attempted programming.

Another aspect of the present invention allows the user to modify theCCA without the interruption of a current infusion. FIGS. 9A to 11illustrate various embodiments of allowing the user to modify the CCA“on the fly.” The ability to change the CCA is this manner increasesuser and workflow efficiency. In particular, the ability to change theCCA while an infusion is running is crucial where a patient is beingtransported from one CCA to another such as from the emergency room (ER)to the OR, or from the OR to the ICU. This ability to change the CCAalso enhances patient safety where time to wait for an infusion to endmay be harmful to the patient. FIGS. 9A to 9G illustrate a series ofscreen shots of a medical device configured to allow the CCA to bechanged while an infusion is ongoing on another channel of themulti-channel pump.

FIG. 9A illustrates that a therapy is delivering on channel A 910 withthe ICU CCA 915. In this example, a user wants to change the CCA andprogram Channel B 920. The user selects channel B by pressing tab B 925,which brings up the channel B programming display screen 930 shown inFIG. 9B. Moving from FIG. 9B to FIG. 9C, the patient information button940 has been pressed. Pressing the patient information button displays apatient information data field 950 for entry of patient data andchanging the CCA 960. When the user presses the CCA button, a “ChangeCCA” message 965 appears requesting that the user confirm that the CCAis to be changed (FIG. 9D). In this example, the user wants to changethe CCA from ICU to Gen Med. To confirm, the user presses the “yes”button 970. In response to the confirmation, a “multiple CCAs” systemmessage 975 appears. To confirm, the user presses the “OK” button 980.Once the OK button 980 has been pressed, the CCA has been changed at 985and a “Done” button 990 is displayed to continue with the programming ofthe infusion at infusion screen 995 (FIG. 9G).

With reference to FIG. 10 , illustrated is a program 1000 for changingthe CCA at a multi-channel medical device 14. Program 1000 starts at1001 and proceeds to block 1005 where it is determined that the user haschanged the CCA. Program 1000 then determines at block 1010 whether thenew CCA is the same as the old CCA for Channel A If yes, the programproceeds to block 1020 to retain the old CCA on Channel A If no, program1000 proceeds to block 1015 to determine whether channel A is idle. Ifyes, program accepts the new CCA on channel A at block 1025. If no,channel A is set to wait at block 1030 until either 1) the user changesthe CCA while waiting on channel A (block 1060), whereby program 1000proceeds to 1005; or 2) channel A becomes idle (block 1065), wherebyprogram 1000 proceeds to block 1025 and accepts the new CCA on channel A

Additionally, when a user has changed a CCA (block 1005), channel B isevaluated. Program 1000 proceeds from block 1005 to block 1035 todetermined whether the new CCA is the same as the old CCA for Channel B.If yes, the program proceeds to block 1045 to retain the old CCA onChannel B. If no, program 1000 proceeds to block 1040 to determinewhether channel B is idle. If yes, program 1000 accepts new CCA onchannel B, block 1050. If no, channel B is set to wait at block 1055until either 1) the user changes the CCA while waiting for channel B(block 1070), whereby program 1000 proceeds to 1005; or 2) channel Bbecomes idle (block 1075), whereby program 1000 proceeds to block 1050and accepts the new CCA on channel B.

With reference to FIG. 11 , illustrated is a program 1100 for changingthe CCA at a single channel medical device. Program 1100 starts at 1101and proceeds to block 1105 where it is determined that the user haschanged the CCA. Program 1100 then determined at block 1110 whether thenew CCA is the same as the old CCA. If yes, the program proceeds toblock 1120 to retain the old CCA. If no, program 1100 proceeds to block1115 to determine whether the channel is idle. If yes, program 1100accepts the new CCA, block 1125. If no, the channel is set to wait atblock 1130 until either 1) the user changes the CCA while waiting (block1160), whereby program 1100 proceeds to 1105; or 2) the channel becomesidle (block 1170), whereby program 1100 proceeds to block 1125 andaccepts the new CCA.

With reference to FIGS. 12A to 13 , illustrated is another aspect of thepresent invention that allows a medical device 14 user to modify theVTBI parameter to specify additional fluid when an infusion is nearingcompletion or is delivering in a KVO (keep vein open) mode. A configuredmedical device that includes a program to allow the additional fluidprovides for more efficient workflow as well as a more efficient user.In one embodiment of the invention, the program for allowing additionalVTBI maintains all other delivery parameters while allowing the user tospecify the additional VTBI. Thus, the user does not have to re-entercommon delivery parameters when only an additional VTBI is needed. Thisreduces programming effort, saves time and reduces the potential forerrors.

FIGS. 12A to 12F illustrate, using a series of screen shots, oneembodiment of a program for modifying the VTBI delivery parameter. AtFIG. 12A, a basic infusion is delivering on channel A, as shown byscreen display 1200. At this point in the infusion, FIG. 12A shows thatthe remaining VTBI is 45.3 ml. FIG. 12B illustrates that the user haspressed “basic” button 1210. A data entry field 1220 appears based onthe pressing of the basic button 1210. At data entry field 1220, theuser can press the particular field to edit. FIG. 12C illustrates thatthe user pressed the VTBI button 1230 to edit the VTBI. In response topressing the VTBI button 1230 a keypad 1240 appears on the displayscreen. Here, the user enters the total amount of VTBI desired. In thisexam pie, the user enters 75 via the keypad 1240 into the data field forVTBI 1245. The user then presses “Enter” 1250 to save the changes andcontinue. Alternatively, the user can press “Clear” 1255 to delete theentry or cancel 1260 to exit without saving the changes. FIG. 12Dillustrates that the VTBI has been changed to 75 ml and entered. FIG.12D also illustrates that the time remaining has been recalculated andis displayed in area 1270 based on the new VTBI displayed in area 1265.At FIG. 12E, a confirmation of titration screen 1275 has appeared toconfirm the new VTBI. The user confirms the change to the VTBI bypressing “Start Titration” button 1280. FIG. 12F illustrates that theinfusion has been updated with the new VTBI and is continuing to run. Inone embodiment, the method illustrated in FIGS. 12A to 12F is used toadd to the VTBI the fluid remaining in the fluid container that iscurrently infusing. In another embodiment, the user may add a newcontainer of fluid as long as all other delivery parameters remain thesame as the currently running infusion.

FIG. 13 is a flow diagram illustrating one embodiment of a method 1300for adding additional VTBI to a current infusion. Method 1300 starts atblock 1301 and proceeds to block 1305 where it is determined that thepump is delivering a programmed therapy. Method 1300 continues at block1310 where the programmed VTBI reached zero and the KVO delivery starts.At block 1315, a user accesses a VTBI programming screen 1220 and entersa VTBI value 1245. The user confirms the new value at block 1320 andstarts the new delivery. Method 1300 ends at 1325. One skilled in theart will appreciate from the disclosure herein that such adding of VTBIcan also be adapted for use in bolus or piggyback situations.

With reference to FIGS. 21A to 22 , one embodiment of the presentinvention provides for improved callback rules for the medical device.Medical devices generally have three classes of callback alarms based onurgency: High Urgency (e.g. Air-In-Line); Medium Urgency (e.g.Inactivity callback); and Low Urgency (e.g. Battery not Charging). Inone embodiment of the invention, the alarms are configured at the druglibrary. In one embodiment, the alarms are configured at the druglibrary based on the CCA in which the medical device resides. In anotherembodiment, the alarms are configured at the drug library master infusersettings so that the alarm configurations apply to all medical deviceswithin the medication management system. In other embodiments, thealarms are configurable by the clinician at the medical device. Forexample, in one embodiment, default alarm settings were configured atthe drug library, and sent to the medical device where, depending on thealarm configuration rules set by the hospital administration, aclinician may modify the alarm based on factors such as the particularCCA, or personal preference.

In one embodiment of the invention, a specific alarm type orconfiguration is assigned to each class of urgency such that a cliniciancan determine the urgency of the callback alarm upon hearing the alarm.In one embodiment of the invention, each class of alarm is assigned adifferent melody, a different tone or series of tones and/or a differentvolume. In other embodiments, the frequency of the alarm is configuredbased on the class of alarm. In other embodiments, the volume, melody,tone and/or frequency may escalate based on a non-response by theclinician.

In one embodiment of the invention, when an audible alarm occurs at themedical device, the audio volume starts at the volume setting configuredat the drug library and or by the clinician. However, if the alarm isnot acknowledged, the volume is automatically escalated to apredetermined volume after a predetermined time out period passes. Inone embodiment, the time out period is configurable at the drug library.In another embodiment, the time out period is configurable at the druglibrary for each particular CCA. In yet another embodiment, the time outperiod is configurable at the medical device. In another embodiment, adefault value for the time out period is set at the drug library and maybe changed at the medical device to a value that does not exceed thedefault value. For example, if the default time out period is 20seconds, the user may set the time out period to less than 20 secondssuch as for 10 seconds. In on embodiment of the invention, the volumeescalates for only those alarms in the High Urgency class of alarms. Inother embodiments, the volume escalates for both High Urgency and MediumUrgency classes of alarms.

In another embodiment of the present invention, the alarm tone escalatesafter a predetermined time out period if the alarm is not acted upon. Inthis embodiment, a default tone set at the drug library may beconfigurable by a user at the medical device. In one embodiment, thepitch of the tone becomes higher when the alarm escalates due to thenon-response of the clinician.

In another embodiment of the present invention, the alarm comprises apredetermined tone melody. In one embodiment, a different tone melody ischosen for each class of alarm urgency or priority. In one embodiment,the High Urgency audible alarm is a sequence of six or seven tones thatcontinually repeat until the alarm is acted upon by the clinician. Inone embodiment, a brief pause of the tone sequence (melody) occursbetween each repeat of the sequence. In one embodiment, the melody forthe High Urgency alarm also escalates in volume with continuedinactivity by the clinician. In one embodiment, the volume of the melodyescalates after a predetermined length of time. In one embodiment, theescalation of volume is configured at the drug library. In anotherembodiment, the volume escalation is set as a default in the druglibrary and is further configurable at the medical device by theclinician.

In another or the same embodiment, the Medium Urgency audible alarm is asequence of three tones. In one embodiment, the tone sequence (melody)repeats after a predetermined length of time if the clinician has notresponded to the alarm. In one embodiment the predetermined length oftime is 1 to 2 minutes. In another embodiment, the predetermined lengthof time is from 1 to 60 seconds. In one embodiment, the predeterminedlength of time is configured at the drug library. In another embodiment,the predetermined length of time is set as a default at the drug libraryand is further configurable by the clinician at the medical device.

In another embodiment, the Low Urgency audible alarm is a sequence oftwo tones. In one embodiment, the tone sequence repeats every two to tenminutes until acted upon by the clinician. The time to repeat may beconfigured as above for the Medium Urgency alarm.

In one embodiment, the High Urgency alarms are configured to have amelody with a very fast paced tempo. While the lesser urgency alarmshave a melody with a slower paced tempo. In one embodiment, an alarmcomprising a melody escalates in tempo when the alarm is not respondedto by the user. In one embodiment, the alarm is configurable by the userat the medical device to a melody of the user's choice. In an example, amelody may be assigned to each user whereby the user sets the alarm oneach medical device the user is responsible for to that one melody. Inthis manner, any one user in a location with multiple users can identifyby sound that the alarm is for a medical device of a patient under theirspecific care.

FIG. 21A illustrates a screen shot of a medical device showing that achannel level callback alarm 2110, 2115 has sounded for each channel Aand B where a therapy was partially programmed and no other action wastaken by the user. FIG. 21B illustrates a device level callback alarm2120 has appeared because no keypress was made while a popup 2125 wasdisplaying.

With regard to FIG. 22 , a flow chart of a program 2200 for escalatingan audible callback alarm, in accordance with the present invention.Program 2200 begins at 2201 and proceeds to block 2205 where an alarmhas been activated. At block 2210, program 2200 determines whether theclinician has acknowledged the alarm during a timeout period. If yes,program 2200 proceeds to end at 2235. If no, program 2200 proceeds toblock 2215 where a determination is made as to whether the currentvolume is at a maximum level. If no, program proceeds to block 2220where the program increases the alarm volume. If yes at block 2215,program 2200 proceeds to block 2225 to determine whether the melody isat a High Urgency and has a melody change been configured. If yes,program 2200 proceeds to end at 2235. If no at block 2225, program 2200proceeds to block 2230 to change the melody. Program 2200 then proceedsto end at block 2235.

When an alarm occurs on a medical device it may apply to the entiredevice (e.g. low battery) or it may only apply to a specific channel(e.g. inactivity callback on channel A). If the alarm is channelspecific, the user needs to navigate to the channel to view what iscausing the callback. In another aspect of the present invention, adevice program automatically takes the user to the precise location ofthe alarm when the user touches the alarm display area on the displayscreen as will be described below with reference to FIGS. 23A to 23C.

FIGS. 23A to 23C are screen shots of a display interface for amulti-channel infusion pump. In this example, the infusion pump has atherapy programmed for both channel A and channel B. Channel A is idlewaiting for the bolus programmed on channel B to complete. FIG. 23Ashows that an alarm 2310 has occurred on channel B based on thecompletion of the bolus infusion programmed on channel B. The druglibrary or the user had previously configured the pump to stop theinfusion or request the pump generate a callback to them when the boluswas complete. When the user presses alarm tab B 2315 the user is takendirectly to the display screen 2320 for channel B. Display screen forchannel B indicates that the bolus is completed.

FIG. 23A also illustrates that an alarm 2325 has occurred for channel AWhen the user presses alarm tab A 2330, the user is taken directly todisplay screen 2335 shown in FIG. 23C. Display screen 2335 indicates tothe user the pump is waiting for input from the user. The user mustclear the alarm and provide the necessary input before the infusionscheduled on channel A may be started by pressing Start 2340. Theability for a user to navigate quickly to the cause of the alarmimproves efficiency of the user as well as workflow. Additionally, theability to navigate directly to the cause of the alarm decreases oreliminates errors that may occur if the user had to take many steps tonavigate to the appropriate display screen.

With reference to FIG. 24 , a flow chart for one embodiment for aprogram 2400 for navigating directly to a cause of an alarm is shown inaccordance with the present invention. Program 2400 begins at block 2401and proceeds to block 2405 where an alarm has been activated. Inresponse to the alarm, an acknowledgement is received from the user inresponse to the user pressing an alarm tab in block 2410. Program 2400determines at block 2415 whether the alarm was for channel A If yes, theprogram proceeds to block 2420 where the program navigates to the screenon channel A from where the alarm is arising if the current screen isallowed to be navigated away from. At block 2425, the user takesappropriate action in relation to the alarm. If, at block 2415, theprogram determines that the alarm is not for channel A, program 2400proceeds to block 2430 where it is determined whether the alarm is forchannel B. If yes, the program proceeds to block 2435 where the programnavigates to the screen on channel B from where the alarm is arising ifthe current screen is allowed to be navigated away from. If at block2430, the alarm is not for channel B, program 2400 proceeds to block2440. At block 2440, the program determines that no navigation isrequired and proceeds to block 2425 where the user is instructed to takea specific action. Program 2400 ends at 2445.

In another embodiment of the present invention, the drug library may beconfigured to allow for a dose back calculation during the programmingof an infusion delivery. During the programming of an infuser for adose-based therapy (e.g. weight or BSA based therapy), the user mustenter the dose first before being allowed to enter the rate. In certainclinical scenarios it is preferable for the user to enter the rate firstand the dose is calculated from the rate. Providing this flexibility tothe user and the hospital administration allows for increased efficiencyand better work flow.

FIG. 25 illustrates a graphical user interface 2500 for configuring adrug library. A default “dose back calculate” can be set at 2510. Toenable the dose back calculation at the medical device, an administratorselects “enabled” 2520. To disable the dose back calculation at themedical device, the administrator selects “disabled” 2530.

FIG. 26A is a screen shots of a medical device that allows for the doseback calculation as determined within the drug library. The user isallowed to enter dose, rate, etc. in any order as further describedbelow. FIG. 26B is a screen shot of a medical device that disallows forthe dose back calculation as determined within the drug library. Theuser is forced by the user interface to enter the dose first.

With reference to FIG. 27 , illustrated is a flow chart of a program2700 residing in the medical device for programming a drug andcalculating a dose. Program 2700 begins at 2701 and proceeds to block2705 where the program determines if the user selected a dose-baseddrug. If not, program 2700 proceeds to block 2710 where program 2700determines whether the dose back calculation is enabled at the druglibrary. If yes, program 2700 proceeds to block 2715, where program 2700enables dose, rate, VTBI, time and/or weight/BSA fields. Program 2700proceeds to 2720 where it is determined whether the user entered thedose or the rate. If dose, program 2700 proceeds to block 2725 tocalculate rate based on the provided dose. If rate, program 2700proceeds to block 2735 to calculate the dose based on the provided rate.

If at block 2710 the dose-back calculation is not enabled, program 2700proceeds to block 2740 where program 2700 enables a dose field as wellas weight/BSA if required. Program 2700 proceeds to block 2745 where adose is provided as well as weight/BSA if required. Next, a rate iscalculated based on the entered dose. Program 2700 proceeds to block2755 where rate, VTBI and time fields are enabled. Program 2700 ends at2730.

One skilled in the art will appreciate from this disclosure that thefunctionality shown in the figures and described herein is made possibleby computer program code, and as such those features could be combined,distributed or shared among the processors of the pump 14, the MMU 12,or other computers within the healthcare facility without detractingfrom the present invention. Those skilled in the art will also recognizefrom this disclosure that selecting the CCA and providing otherinformation or input can be done via scanning or passively receivinginput from drug containers, a patient identifier, a nurse identifier orother similar items.

While the embodiments of the invention disclosed herein are presentlyconsidered to be preferred, various changes and modifications can bemade without departing from the scope of the invention. The scope of theinvention is indicated in the appended claims, and all changes andmodifications that come within the meaning and range of equivalents areintended to be embraced therein.

1.-2. (canceled)
 3. A method of managing an infusion pump system, themethod comprising: scanning a first barcode securely attached to apatient; scanning a second barcode on a medication container associatedwith the patient; scanning a third barcode corresponding to a channel ofan infusion pump; and generating a near view user interface includingprogramming information based on the scanning of the first barcode, thesecond barcode, and the third barcord, wherein the scanning of the firstbarcode, the second barcode and the third barcode enable association ofthe infusion pump with the patient and the medical container.
 4. Themethod of claim 3, further comprising displaying a volume to be infused.5. The method of claim 3, further comprising including a user input,wherein the user input is configured to confirm the programminginformation.
 6. The method of claim 3, further comprising displaying arate of infusion.
 7. The method of claim 3, further comprisingdisplaying a duration of infusion.
 8. The method of claim 3, furthercomprising transitioning the near view user interface to a far view userinterface after receiving a confirmation of the programing informationfrom a user.
 9. A system of managing an infusion pump system, the systemcomprising one or more hardware processors further configured to: scan afirst barcode securely attached to a patient; scan a second barcode on amedication container associated with the patient; scan a third barcodecorresponding to a channel of an infusion pump; and generate a near viewuser interface including programming information based on the scanningof the first barcode, the second barcode, and the third barcode, whereinthe scanning of the first barcode, the second barcode and the thirdbarcode enable association of the infusion pump with the patient and themedical container.
 10. The system of claim 9, wherein the one or morehardware processors are further configured to display a volume to beinfused.
 11. The system of claim 9, wherein the one or more hardwareprocessors are further configured to include a user input, wherein theuser input is configured to confirm the programming information.
 12. Thesystem of claim 9, wherein the one or more hardware processors arefurther configured to display a rate of infusion.
 13. The system ofclaim 9, wherein the one or more hardware processors are furtherconfigured to display a duration of infusion.
 14. The system of claim 9,wherein the one or more hardware processors are further configured totransition the near view user interface to a far view user interfaceafter receiving a confirmation of the programing information from auser.